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PREFACE 


This  work  was  completed  as  part  of  Work  Unit  77191927,  Development  of  MPT  Acquisition  Tradeoff 
Methods.  This  report  provides  a  user’s  manual  for  a  demonstration  model  for  the  Weapon  System 
Optimization  Model  (SYSMOD)  concept  for  manpower,  personnel,  and  training  (MPT)  resourcing  and 
costing  during  the  Concept  Exploration  phase  of  weapon  system  acquisition.  Although  notional, 
SYSMOD  does  provide  a  basis  for  much  of  the  design  work  leading  to  the  MPT  in  Acquisition  Decisioil 
Support  System  (MPT  DSS)  project  being  accomplished  under  Work  Unit  29220302. 
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1.  INTRODUCTION 


A  demonstration  version  (DemoJ  of  the  Weapon  System  Optimization  Model  (SYSMOD) 
for  Concept  Exploration  was  built  to  illustrate  the  operation  of  the  model  proposed  in  the  first 
SYSMOD  effort.  The  Demo  proved  valuable  in  developing  the  conceptual  framework  and  R&D 
plan  by  helping  us  visualize  the  interaction  between  the  components  or  modules  that  will  comprise 
SYSMOD.  The  Demo  also  helps  explain  the  framework  to  users  to  elicit  information  needed  to 
build  the  model.  Moreover,  the  Demo  may  prove  to  be  an  effective  training  tool  to  convey  the 
concept,  operation,  and  benefits  of  SYSMOD  to  potential  users  in  the  Air  Force. 

1.1  OBJECTIVE 

Tire  objective  of  this  interactive  Demo  is  to  illustrate  the  SYSMOD  concept  and  to  show  how 
it  will  be  applied  during  Concept  Exploration.  SYSMOD  is  an  integrated  system  of  existing  and  new 
manpower,  personnel,  and  training  models  for  use  in  the  weapon  system  acquisition  process.  The 
screens  in  this  Demo  guide  the  user  through  the  process  of: 

a.  Defining  operation  and  support  scenarios  that  will  be  used  to  simulate  the 
maintenance  of  the  proposed  new  weapon  .system; 

b.  Running  a  simulation  to  determine  whether  the  available  manpower  meets  the 
imposed  criteria  for  weapon  system  availability  and  cost;  and, 

c.  Conducting  machine-to-machine.  man-to-machine,  and  man-to-man  trade-offs  that  will 
drive  subsequent  simulations  so  that  the  user  can  determine  a  good,  cost-effective  mix 
of  maintenance  hardware  and  Manpower-Personnel-Training  (MPT)  resources. 


For  purposes  of  this  demonstration  we  have  simplified  the  level  of  weapon  system  complexity 
in  favor  of  focusing  on  the  SYSMOD  methodology.  For  that  reason  the  weapon  systems  and  Air 
Force  Specialties  (AFSs)  are  primarily  notional,  although  we  tried  to  maintain  some  semblance  of 
reality. 

1.2  MENU  HIERARCHY 

The  hierarchy  in  Figure  1  is  provided  as  a  roadmap  to  guide  the  user  through  the  Demo. 
Each  vertical  bar  represents  a  menu;  branches  continue  to  the  right  to  show  screens  and  menus 
nested  behind  each  option  on  a  menu.  In  Figure  1,  BCS  stands  for  Baseline  Comparison  System  and 
MTBF  stands  for  Mean  Time  Between  Failures.  To  execute  an  option  on  any  menu  highlight  the 
appropriate  option  and  press  the  <Enter>  key.  To  move  around  inside  a  form,  use  the  arrow  keys 
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and  the  <PgUp>  and  <PgDn>  keys.  To  return  to  the  previous  menu  or  form,  press  the  <Esc> 
key.  To  move  down  to  a  form  which  lies  beneath  another  form  in  the  menu  tree,  press  the  control 
key  and  simultaneously  press  the  <PgDn>  key  (i.e.  <Ctrl>PgDn).  The  bottom  of  each  form 
contains  information  about  which  keys  perform  the  various  functions. 
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2.  USING  THE  DEMO 


To  activate  the  SYSMOD  Demo  and  enter  the  main  menu,  the  user  should  type  "SYSMOD" 
and  press  the  <Enter>  key.  Before  entering  the  main  menu,  the  user  will  view  a  SYSMOD  logo 
followed  by  a  screen  explaining  the  purpose  of  the  Demo.  Press  the  <Ctrl>  PgDn  key  to  pass  the 
logo  screen,  and  press  the  <Esc>  key  to  pass  the  explanation  screen. 

To  load  a  previously  saved  simulation,  select  "Edit  Existing  Scenario  from  the  first  menu. 
The  Demo  will  prompt  the  user  for  a  file  to  read.  Press  the  <lnsert>  key  to  view  a  list  of  previously 
saved  files.  Once  the  user  selects  a  file  to  load,  the  SYSMOD  main  menu  will  open.  Selecting  the 
"Create  a  New  Scenario"  option  loads  default  data  and  starts  the  SYSMOD  main  menu.  User 
generated  scenarios  are  stored  in  DOS  files  with  the  extension  .smd. 

2.1  MAIN  MENU 

The  SYSMOD  Demo  main  menu  consists  of  five  options:  Build  Model  of  Maintenance 
System,  Execute  Model,  Evaluate  Results,  Perform  Trade-off  Analysis,  and  Save  the  Scenario  to  a 
File.  Each  of  these  five  options  is  described  in  turn. 

2.2  BUILD  MODEL  OF  \UINTENANCE  SYSTEM 

When  this  option  is  selected,  the  Demo  presents  the  user  with  a  sub-menu  of  options.  The 
purpose  of  this  menu  branch  is  to  enter  all  of  the  input  variables  for  the  simulation.  When  creating 
a  new  scenario,  the  user  should  execute  the  options  in  the  order  they  are  presented.  If  the  options 
are  not  selected  in  order,  data  input  may  be  incomplete  and  the  user  may  encounter  error  messages 
when  running  the  model.  To  avoid  incomplete  data  input,  the  model  loads  default  data  from  the  file 
db_data.asc  upon  selection  of  an  existing  weapon  system  in  the  Construct  Baseline  Comparison 
System  branch.  When  creating  a  new  scenario,  the  user  should  check  every  input  screen.  The  color 
scheme  of  this  menu  branch  is  white  and  yellow  on  blue. 

2.2.1  Construct  Baseline  Comparison  System 

The  user  is  expected  to  enter  the  baseline  or  parent  system  for  the  three  notional  subsystems 
for  the  aircraft,  namely  Airframe:  Subsystem  One,  Propulsion:  Subsystem  Two,  and  Communication, 
Navigation,  and  Identification  Friend  or  Foe  (COMM/NAV/IFF):  Subsystem  Tliree.  When  the  user 
presses  the  <Enter>  key  on  any  of  the  three  subsystem  fields,  a  pop-up  menu  with  two  options 
appears.  Each  option  allows  the  user  to  use  as  a  baseline,  data  from  an  existing  weapon  system  (in 
this  case  the  F-15  or  F-16  fighter  aircraft).  For  the  purposes  of  this  Demo,  we  have  used  notional 
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data  for  each  of  these  options.  The  user  selects  one  of  the  options  (either  the  F-15  or  the  F-16 
fighter)  to  provide  the  Demo  with  the  appropriate  data.  Note  that  a  selection  must  be  made  for  all 
of  the  subsystems  or  the  Demo  will  not  operate  correctly.  There  is  one  screen  on  this  menu  branch. 

2.2.2  Enter  Variable  Options 

In  this  branch  the  user  chooses  units  of  measure  for  two  inputs.  First,  select  whether  to 
conduct  the  analysis  using  grade  or  skill  level  as  a  measure  of  experience  for  flighthne  and  base  level 
maintainers.  Second,  select  whether  to  conduct  the  analysis  using  sorties  or  flying  hours.  Sorties 
might  be  selected  for  analysis  of  a  scenario  involving  short  missions;  while  flying  hours  might  be 
selected  for  analysis  of  a  scenario  involving  long  missions.  There  is  only  one  screen  on  this  menu 

branch. 

2.2.3  DeFine  Maintenance  Network 

This  series  of  screens  allows  the  user  to  define  the  maintenance  network  needed  to  service 
the  weapon  system  under  development.  There  are  three  levels  of  repair  in  this  maintenance  network. 
The  first,  the  flighthne  level,  represents  the  maintenance  that  is  performed  to  remove  and  replace 
or  to  conduct  a  minor  repair  action.  The  second,  the  intermediate  level,  is  located  on  the  base  and 
operated  by  the  wing.  A  Line  Replaceable  Unit  (LRU)  from  the  subsystem  in  question  is  removed 
on  the  flightline  and  sent  to  the  base  or  intermediate  repair  facility  to  be  diagnosed  and  possibly 
repaired.  The  third  level,  the  depot  level,  is  a  centralized  repair  location  where  Shop  Replaceable 
Units  (SRUs)  or  parts  of  the  LRU  are  repaired  or  discarded.  The  user  has  the  option  to  include 
base  level  maintenance  for  each  subsystem  in  the  model.  When  the  user  presses  the  <Enter>  key 
on  any  of  the  three  fields  at  the  base  level,  he  or  she  sees  a  pop-up  menu  with  two  options.  By 
selecting  "On",  the  user  includes  base-level  repair  for  the  appropriate  subsystem.  By  selecting  "Off, 
the  user  limits  maintenance  to  that  performed  at  the  flightline  level.  The  Demo  requires 
maintenance  on  the  flighthne  ("hard-coded  in")  and  does  not  model  maintenance  at  the  depot  level 
("hard-coded  out"). 

After  selecting  which  sub.systems  will  have  ba.se  level  maintenance,  pressing  < Ctrl > PgDn 
presents  a  sub-menu  with  options  to  examine  the  maintenance  network  in  further  detail.  Selecting 
an  item  on  the  menu  produces  a  screen  with  a  schematic  portrayal  of  the  maintenance  network. 
Figure  2  shows  the  screen  for  the  flightline  level  maintenance  network,  while  Figure  3  shows  the 
screen  for  the  base  level  maintenance  network.  The  purpose  of  these  screens  is  to  assign  the  AFS 
(in  the  field  labeled  "AFS"),  the  number  in  the  workcrew  (in  the  field  labeled  "Number"),  the  amount 
of  time  required  to  perform  the  various  tasks  (in  the  field  labeled  "Time")  and  the  probability  that 
a  particular  item  will  follow  one  of  the  branches  (in  the  field  labeled  Prob  ). 
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To  understand  the  flightline 
level  maintenance  network  shown  in 
Figure  2,  consider  that  for  each 
subsystem,  when  a  malfunction  occurs, 
that  subsystem  follows  the  path  of  the 
maintenance  network  in  order  to  be 
repaired.  The  subsystem  begins  at  the 
box  titled  "Subsystem  Aircraft"  and 
works  its  way  through  the  network 
following  the  solid  lines.  In  the  example 
in  Figure  2,  the  subsystem  is  analyzed  by 
a  team  of  three  maintainers  of  notional  AFS  1.  (Also  labeled  AFS  458X2_X,  this  is  the  Air  Force 
Specialty  Code  (AFSC)  for  an  air  frame  repairer  where  the  first  X  indicates  an  unspecified  skill  level 
and  the  second  X  indicates  flightline).  The  time  to  task  completion  is  1.0  hours.  At  this  point,  the 
LRU  enters  one  of  the  three  branches.  First,  the  LRU  might  be  removed  and  replaced  and  sent  to 
the  intermediate  repair  level  for  further  diagnosis  (with  a  .5  probability).  Second,  the  maintainers 
could  find  no  problem  with  the  LRU  and  declare  the  failure  to  be  spurious  labeling  it  "Cannot 
Duplicate"  (with  a  .3  probability).  Third,  the  LRU  could  be  repaired  on  the  flightline  under  "Minor 
Repair"  (with  a  .2  probability).  Finally,  the  LRU  is  tested  on  the  aircraft  in  the  "Verify  Action"  step. 

Figure  3  shows  the  maintenance 
network  for  base  level  repair.  When  an 
LRU  is  removed  during  flightline 
maintenance,  it  is  sent  to  the 
intermediate  level,  the  back  shop  or 
base  level  shop,  for  repair.  A  team  of 
troubleshooters  analyzes  the  LRU  (in 
Figure  3,  a  mean  time  to  repair  of  7.0 
hours)  and  determines  either  that  it 
needs  a  major  repair  (with  .4  probability 
in  Figure  3)  or  that  it  cannot  be  fixed 
and  sends  it  to  salvage  (with  .6 
probability). 

To  define  the  workcrew  in  terms  of  training,  experience  and  aptitude  requirements,  press  the 
<Enter>  key  twice  on  the  "Number"  field.  This  brings  up  a  screen  outlining  these  elements  and 
allows  for  changes.  (Figure  4.)  The  screen  allows  for  editing  several  variables.  These  include  the 
skill  level  or  grade  of  each  member  of  the  workcrew,  the  total  weeks  of  training  (classroom  and  Field 
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Training  Detachment  (FTD)),  and 
aptitude  of  the  maintainer  required  for 
the  task. 

Note  that  selecting  a  value  in 

the  AFS  field  (AFS  =  1 . 6)  selects  a 

notional  code  (APSC)  for  the  specialty, 
not  the  number  of  AFSs  or  people 
performing  the  task.  The  field  for 
displaying  the  AFSC  changes 
automatically  when  the  user  changes  the 
value  in  the  AFS  field. 

2.2.4  Develop  Simulation  Parameters 

The  screen  entitled  "Build  Simulation  Scenario"  allows  the  user  to  define  up  to  five  types  of 
missions  that  the  aircraft  will  fly.  (Figure  5.)  Tlie  user  should  enter  the  number  of  missions  required 
per  day,  the  number  of  aircraft  required 
to  perform  the  mission,  and  the  length 
(in  hours)  of  the  mission.  The  number 
of  aircraft  is  hard-coded  in  at  72.  There 
are  two  possible  errors  that  the 
SYSMOD  Demo  ensures  against.  First, 
the  user  must  enter  values  for  at  least 
one  mission  or  the  Demo  will  not  allow 
the  user  to  leave  the  screen  and 
continue  with  the  simulation.  Second,  if 
the  user  enters  more  missions  than  the 
wing  can  possibly  support  and  tries  to 
exit  this  screen,  an  error  message  will  appear  indicating  that  the  user  must  correct  the  error  before 
returning  to  the  program.  There  is  one  screen  on  this  menu  branch. 

2.2.5  Define  Level  of  Spares 

The  screen  entitled  "Machine  Supportability  Factors"  allows  the  user  to  define  the  monthly 
spares  purchase  (units  are  numbers  of  spare  LRUs),  the  cost  of  one  spare  LRU  (in  thousands  of 
dollars)  and  the  Mean  Time  Between  Failures  (MTBF)  (measured  in  numbers  of  sorties  or  flying 
hours)  for  each  subsystem.  (Figure  6.)  This  screen  allows  for  changes  to  three  parameters  that 
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interact.  Note  that  a  certain  number  of 
spare  LRUs  must  be  purchased  monthly 
to  satisfy  losses  during  the  simulation. 

That  is,  in  accordance  with  the  defined 
maintenance  network,  a  certain  number 
of  LRUs  cannot  be  repaired  and  must 
be  thrown  away.  Those  that  are  thrown 
away  must  be  replaced  through  the 
monthly  LRU  purchase,  otherwise  the 
simulation  will  show  a  loss  of  sortie 
generation  potential.  This  process  is 
explained  in  greater  detail  in  Section  8  of  the  Appendix.  By  pressing  <Enter>  on  the  "Monthly 
Spares  Purchase"  fields,  the  user  can  see  if  the  demand  for  spares  on  that  particular  subsystem  is  met. 
When  the  demand  is  not  met,  a  warning  message  tells  the  user  how  many  spares  are  required  to  avoid 
losing  sorties.  There  is  only  one  screen  on  this  menu  branch. 

2.2.6  Identify  Manpower  Levels 

The  screen  entitled  "Manpower  Constraints"  allows  the  user  to  enter  the  matrix  of  maintainers 
available  to  the  simulation  for  each  skill  level  of  each  notional  AFS.  The  AFSs  are  listed  vertically 
and  experience  levels  are  listed  horizontally.  Each  field  in  the  matrix  corresponds  to  the  number  of 
maintainers  available  for  the  experience  level  at  the  top  of  the  column  and  for  the  AFS  at  the  far 
left  of  the  row. 

Pressing  < Ctrl  >  PgDn  allows  the  user  to  identify  the  percentage  of  time  spent  on  overhead 
tasks  for  flightline  and  base-level  maintenance.  The  default  value  of  22%  is  the  same  value  typically 
used  in  the  Logistics  Composite  Model  (LCOM);  however,  this  variable  can  be  edited.  Shift  policy 
cannot  be  changed  from  its  default  value  of  three  shifts  per  day. 

2.2.7  Define  Training  Costs 

This  screen  allows  the  user  to  define  the  training  costs.  Costs  are  defined  in  thousands  of 
dollars  per  week.  Training  costs  are  entered  for  each  experience  level  of  each  notional  AFS  (four 
experience  levels  and  six  notional  AFSs  for  a  total  24  data  entry  fields).  The  number  of  weeks 
required  for  training  an  AFS  is  a  function  of  classroom  and  FTD  skills  required  for  the  skill  level  or 
grade  as  defined  in  the  maintenance  networks.  Further  discussion  of  the  methodology  involved  in 
generating  the  length  of  training  can  be  found  in  Section  5  of  the  Appendix.  There  is  only  one 
screen  on  this  menu  branch. 


Figure  6.  Machine  Supportability  Factors 
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2.2.8  Define  Cost  Factors 


This  screen  allows  the  user  to  define  the  yearly  wage  costs.  Wage  costs  are  defined  in 
thousands  of  dollars  per  year.  Data  are  entered  for  each  experience  level  of  each  notional  AFS,  as 
in  Section  2.2.7  above.  There  is  only  one  screen  on  this  menu  branch. 

23  EXECUTE  MODEL 

Selecting  this  option  runs  the  "simulation",  which  takes  only  a  few  seconds  to  finish.  The  word 
simulation  is  in  quotes  since  the  SYSMOD  Demo  is  not  actually  a  simulation  but  a  compilation  of 
several  expected  value  formulas  used  to  approximate  the  results  of  a  simulation.  Before  running  the 
model  make  sure  you  have  completed  the  data  entry  process.  If  a  scenario  was  loaded  from  an 
existing  file  with  a  complete  data  set,  you  can  execute  the  simulation  without  going  through  the  data 

entry  process. 

2.4  EVALUATE  RESULTS 

This  menu  allows  the  user  to  view  and  evaluate  the  results  of  the  simulation.  If  the  required 
system  performance  is  not  met.  the  user  should  provide  more  resources  until  it  is  met.  The  color 
scheme  of  this  menu  branch  is  white  and  yellow  on  red. 


2.4.1  Operating  Results 

The  screen  entitled  "Summary" 
allows  the  user  to  see  whether  the 
desired  sortie  rate  can  be  achieved. 
(Figure  7.)  If  the  simulation  yields  a 
constrained  sortie  rate  that  exceeds  the 
desired  sortie  rate,  then  the 
maintenance  resources  input  to  the 
model  are  sufficient  to  perform  the 
required  maintenance.  The  numbers  in 
the  fields  are  the  total  number  of  sorties 
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Figure  7.  Sortie  Generation  Summary 
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or  flying  hours  (depending  upon  what  the  user  selected  on  the  input  screens)  to  be  fiown  by  all  the 
aircraft  in  the  wing  in  one  day.  Differences  between  the  constrained  (i.e.  simulated)  and  desired 
sortie  rates  suggest  that  resources  can  be  reduced  or  increased;  either  has  implications  for  the 
system’s  Life  Cycle  Costs  (LCCs).  A  complete  discussion  of  the  expected  value  calculations  used  to 
derive  the  results  in  this  screen  is  located  in  Section  1  of  the  Appendbc. 
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Pressing  <  Ctrl  >  PgDn  reveals 
the  "Results"  screen  which  compares 
manpower  positions  required  with 
positions  authorized.  (Figure  8.)  The 
column  "Total  Workload  Requirements" 
shows  the  number  of  people  in  an  AFS 
required  to  perform  the  assigned  tasks. 
The  column  "No.  of  Positions 
Authorized"  shows  the  number  of 
positions  of  a  particular  AFS  that  were 
authorized  by  the  user.  The  column 


Figure  8.  Manpower  Results 


entitled  "Delta"  shows  shortages  and  overages. 


2.4.2  Workload  Requirements 

The  screen  entitled  "Simulation 
of  Performance  and  Workload"  shows 
the  workload  in  terms  of  number  of 
people  required  for  each  AFS. 

(Figure  9.)  The  workload  for  each  AFS 
is  computed  using  the  algorithms 
outlined  in  Sections  2  and  3  of  the 
Appendix.  The  number  of  Base 
Operating  Support  (BOS)  people  is 
estimated  as  a  proportion  of  the  number 
of  maintainers,  as  explained  in  Section  Simulation  of  Performance  and  Workload 

4  of  the  Appends. 

By  pressing  <F4>  the  user  can  see  a  breakdown  of  the  workload  by  skill  level.  These 
estimates  are  rounded  up  to  estimate  manning  requirements.  By  pressing  <F6>  the  user  can  see  a 
breakdown  of  the  workload  by  task  for  each  subsystem. 


2.4.3  Life  Cycle  Costs 

The  screen  entitled  "Life  Cycle  Cost  Estimation"  shows  the  total  maintenance  costs  for 
manpower  (both  pay  and  training  costs)  and  hardware  incurred  over  the  specified  life  cycle. 
(Figure  10.)  The  model  includes  inflation  rates,  which  the  user  can  enter  or  change  if  required. 
Enter  the  inflation  rate  in  decimal  form  (i.e.  enter  10%  as  0.10). 
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Pressing  <  Ctrl  >  PgDn  shows  the 
form  "Discounted  Summsry  of  Costs  . 

(Figure  11.)  This  form  displays  the 
discounted  present  value  of  the  LCCs 
computed  for  the  simulation.  The  user 
should  enter  a  discount  rate  (enter  10% 
as  10)  and  the  projected  system  life 
cycle  (in  years). 

If  the  LCCs  are  too  high,  the 
user  needs  to  access  the  trade-off 
section  to  design  alternative  resource 
combinations  that  will  reduce  LCCs. 

Once  the  new  resource  combinations 
are  determined,  the  model  inputs  should 
be  changed  to  reflect  the  new  resources 
and  the  simulation  must  be  rerun. 

2.5  PERFORM  TRADE-OFF 
ANALYSIS 

The  trade-off  section  provides  access  to 
several  models  that  allow  the  user  to  investigate  effects  of  changes  of  one  resource  on  maintenance 
performance  and  LCCs.  Both  hardware  and  MPT  resource  trade-off  models  are  available.  The 
trade-off  models  contain  options  to  change  simulation  input  and  to  rerun  the  simulation  with  the 
changes.  Available  trade-offs  include  performing  trade-offs  among  hardware  resources  (machine- 
machine),  between  MPT  resources  and  hardware  (man-machine),  and  among  MPT  resources  (man- 
man).  The  color  scheme  for  this  menu  branch  is  white  and  yellow  on  black. 

2.5.1  Machine  -  Machine  Trade-Offs 

Selecting  this  option  allows  the  user  to  perform  trade-offs  among  hardware  resources.  Figure  12 
shows  the  SYSMOD  Demo  screen  for  this  trade-off.  The  user  can  vary  the  MTBF  and  the  cost  of 
an  individual  spare.  A  proportional  relationship  between  the  two  variables  is  assumed  (i.e.  an  X 
percentage  increase  in  the  MTBF  will  cause  an  "X"  percentage  increase  in  the  price  of  a  spare)  based 
on  the  hypothesis  that  MTBF  can  be  increased  with  high  technology,  but  high  technology  costs  more 
than  low  technology.  After  changing  any  of  the  values  in  the  MTBF  fields,  the  user  should  press 
<F2>  to  see  the  resulting  change  in  the  cost  of  spares.  Pressing  <F4>  will  return  the  variables  to 
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their  original  values  (the  values  used  in 
the  latest  simulation  run).  Pressing 
<F6>  will  re-run  the  model  using  the 
new  values  on  this  screen.  By  changing 
the  value  of  the  spares  cost  and  pressing 
<F8>,  the  value  of  the  spares  cost  will 
change  without  changing  the  value  of 
the  MTBF  (but  you  will  need  to  re-run 
the  model  by  pressing  <F6>).  The 

<F8>  key  is  useful  if  the  user  does  not 

,  ,  ,•  ,  Fioure  12.  Machine  -  Machine  Trade-Offs 

want  to  use  the  assumed  proportional  » 

relationship  between  MTBF  and  the  price  of  spares.  The  underlying  computations  for  this  trade-off 
are  outlined  in  Section  6  of  the  Appendix. 

2.5.2  Man  -  Machine  Trade-Offs 

Selecting  this  option  allows  the  user  to  perform  trade-offs  between  MPT  and  hardware 
resources.  There  are  two  options  available  on  this  menu  branch.  In  the  first  the  user  can  perform 
trade-offs  between  MTBF  and  the  required  workload  of  [lightline  level  maintainers.  In  the  second, 
the  user  can  perform  trade-offs  between  Base  Level  maintainer  workload  and  the  number  of  spare 
LRUs. 

MTBF  -  Flightline  Workload 

Selecting  the  MTBF  -  Flighiline  Workload  option  lets  the  user  see  how  the  flightline  level 
workload  varies  with  MTBF.  The 
SYSMOD  Demo  screen  for  this  trade¬ 
off  is  shown  in  Figure  13.  Changing  the 
reliability  of  a  subsystem  has  an  inverse 
effect  on  the  number  of  maintainers 
required,  i.e.  an  increase  in  reliability 
results  in  a  requirement  for  fewer 
maintainers  required.  Changing  the 
reliability  of  one  subsystem  affects  every 
AFS  that  is  assigned  a  task  for  that 
subsystem.  The  analytical  foundations 
for  this  trade-off  screen  are  explained  in 
Section  7  of  the  Appendix.  Enter  a  new  value  for  the  MTBF  and  press  <F2>  to  see  the  changes 
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in  the  flighlline  level  workload.  Press  <F4>  to  return  to  the  original  numbers,  or  press  <F6>  to 
re-run  the  simulation  based  upon  the  new  values  for  the  MTBF. 

Base  Level  Workload  -  Number  of  Spares 

Selecting  the  Base  Level  Workload  -  Number  of  Spares  option  lets  the  user  change  the 
number  of  base  level  maintainers  to  see 
the  effect  on  the  number  of  LRUs 
required  to  meet  the  demand  for  spare 
LRUs.  Figure  14  shows  the  SYSMOD 
Demo  screen  for  this  trade-off.  Enter  a 
new  number  for  base  level  maintainers 
and  press  <F2>  to  obtain  the  new 
requirement  for  spare  LRUs.  Press 
<F4>  to  return  all  of  the  values  to 
their  original  state.  Note  that  the  level 
of  spares  that  initially  appears  on  this 
trade-off  screen  is  the  minimum  number 
of  spare  LRUs  required  to  meet  the  demands  set  by  the  user  input  sortie  rate.  The  number  of  spare 
LRUs  required  by  the  model  falls  between  an  upper  and  lower  bound.  The  lower  bound  occurs  when 
there  are  no  shortages  in  base  level  maintainers.  Note  that  this  number  is  probably  not  zero  because 
of  the  way  the  maintenance  network  is  set  up.  There  will  be  a  certain  percentage  of  spares  that 
cannot  be  fixed  and  must  be  thrown  away.  This  establishes  the  minimum  number  of  spare  LRUs 
required;  any  fewer  would  cause  a  loss  of  sortie  generation  potential.  There  is  also  an  upper  bound 
on  required  spare  LRUs.  This  level  occurs  when  there  are  no  base  level  maintainers  to  handle  that 
subsystem’s  base  level  tasks  or  when  base  level  maintenance  was  not  selected  in  the  input  screens. 
This  number  represents  the  upper  bound  on  spare  LRUs  required  to  meet  the  demand  for  spare 
LRUs  without  a  loss  of  sortie  generation  potential. 

The  number  of  base  level  maintainers  required  falls  in  a  range  from  zero  to  some  upper 
bound.  The  upper  bound  on  base  level  maintainers  is  the  number  of  base  level  maintainers  required 
to  meet  demand  while  keeping  the  monthly  spare  LRUs  purchase  to  its  lower  bound.  The  initial 
numbers  on  this  trade-off  screen  show  the  numbers  of  base  level  maintainers  at  their  upper  bounds 
and  the  numbers  of  spare  LRUs  at  their  lower  bounds.  Therefore,  raising  the  number  of  base  level 
maintainers  from  the  initial  value  on  this  screen  will  have  no  effect  on  the  requirement  for  spare 
LRUs.  Similarly,  reducing  the  number  of  spare  LRUs  will  have  no  effect  on  the  requirement  for 
base  level  maintainers;  however,  it  will  reduce  the  sortie  generation  potential  for  the  scenario. 
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Further  discussion  of  the  relationship  between  spare  LRUs  and  base  level  maintainers  can  be  found 
in  Section  9  of  the  Appendix. 

2.5J  Man  -  Man  Trade-Offs 

Selecting  this  option  allows  the  user  to  conduct  trade-off  analyses  among  MPT  resources. 
There  are  two  options  available  on  this  menu  branch.  The  first  option  allows  the  user  to  reallocate 
the  specific  tasks  to  different  AFSs.  The  second  option  lets  the  user  conduct  trade-offs  between  the 
level  of  experience  of  the  maintainers  and  the  Mean  Time  To  Repair  (M  i  l  K)  for  a  particular  task. 
Flightline  and  base  level  tasks  for  the  two  options  are  considered  on  separate  screens. 

Reallocate  Tasks  to  AFSs 

Since  separate  screens  are  used  to  reallocate  MPT  resources  for  flightline  and  base  level 
maintainers,  select  the  maintenance 
level  you  would  like  to  change.  The 
following  instructions  apply  to  both  the 
flightline  and  the  base-level  branches. 

Task  Reallocation  trade-offs  allow  the 
user  to  change  the  AFS  assigned  to  a 
specific  task.  Figure  15  shows  this 
trade-off  screen  for  the  flightline  le%'el. 

The  tasks  for  each  subsystem  are  listed 
as  rows  on  the  left  half  of  the  screen. 

The  columns  are  the  three  AFS’s.  The 
user  places  an  "X”  in  the  appropriate 
space  to  select  a  particular  AFS  for  a  specific  task.  Since  only  one  AFS  is  allowed  to  participate  in 
the  workcrew  of  any  one  task,  selecting  an  "X"  in  one  field  automatically  places  an  "O"  (denoting  that 
the  AFS  has  no  part  in  that  task)  in  all  other  AFSs  for  that  task.  Press  <F2>  to  see  how  this 
reallocation  changes  the  relevant  statistics,  i.e.  total  manning  and  training  and  wage  costs,  both  in 
thousands  of  dollars.  Press  <F4>  to  return  to  the  original  values  that  existed  at  the  end  of  the  last 
simulation.  Press  <F6>  to  re-run  the  simulation  with  the  new  data.  Sections  2  and  3  of  the 
Appendix  explain  the  analytical  process  of  finding  the  workload  for  each  task  and  then  computing 
the  workload  for  each  AFS.  Reallocating  a  task  to  a  different  AFS  also  has  implications  for  training 
times.  Because  the  training  time  for  tasks  can  be  affected  by  training  required  for  other  tasks,  total 
training  time  for  an  AFS  may  not  be  simply  the  sum  of  the  training  times  for  its  tasks.  The  training 
cost  fields  on  this  screen  show  whether  the  effects  of  the  reallocation  have  a  positive  or  negative 


Figure  15.  MPT  Resource  Reallocation  Trade-Offs 
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effect  on  training  costs.  The  formulation  of  training  times  for  AFSs  is  discussed  in  Section  5  of  the 
Appendix. 

Perform  Trade-Offs  with  Experience  Level  and  Task  Time 

Trade-offs  between  Experience 
Level  and  Task  Time  allow  the  user  to 
change  the  experience  level  (i.e.  the 
skill  level  or  grade)  of  the  maintainers 
in  the  workcrew  for  a  given  task  and  see 
the  effects  on  the  Mean  Time  To 
Repair  (M  I'J  R)  for  that  task. 

Figure  16  shows  the  screen  for  this 
trade-off.  Each  workcrew  has  one  to 
three  maintainers,  and  each  member  of 
the  crew  may  have  a  different 
experience  level.  SYSMOD  assumes  that  a  maintainer  with  more  training  and  experience  can 
perform  a  given  task  faster  than  one  with  less  training  and  experience.  The  Man  -  Man  trade-off 
allows  the  user  to  examine  the  interaction  of  experience  level  and  task  time.  The  analytical 
relationships  are  explained  in  detail  in  Section  10  of  the  Appendix. 

The  following  instructions  apply  to  both  the  flightline  and  base  level  screens.  Specific  tasks 
for  each  subsystem  are  listed  as  rows  on  the  left-hand  side  of  the  screen.  The  skill  levels  or  grades 
for  each  maintainer  (1,  2  and  .1)  are  given  as  columns.  Each  task  can  have  a  workcrew  of  up  to  three 
maintainers,  each  with  his  or  her  own  skill  level  or  grade.  If  only  one  or  two  maintainers  are  needed, 
the  other  columns  are  set  to  zero.  Relevant  data  for  each  AFS,  such  as  total  manning  and  wage 
costs,  are  given  along  the  right  side.  Note  that  as  maintainer  experience  and  training  increase, 
maintainer  wages  increase  though  total  manning  required  may  decrease.  The  total  manning  fields  on 
the  right  of  the  screen  show  the  total  manning  for  each  AFS  before  the  changes  (top  row)  and  after 
(bottom  row).  Similarly,  the  total  wage  costs  for  each  AFS  (and  the  sum)  are  shown  before  changes 
(top  row)  and  after  (bottom  row). 

To  make  changes  in  the  model,  press  <F2>  to  see  how  changes  in  experience  level  affect 
the  relevant  statistics.  Press  <F4>  to  return  to  the  original  data  used  in  the  latest  simulation  run. 
Press  <F6>  to  re-run  the  simulation  using  the  new  data.  Rerunning  the  simulation  will  reset  the 
original  values  to  the  new  values  found  by  executing  the  trade-off. 


Figure  16.  Experience  -  Task  Time  Trade-Offs 
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2.6  SAVE  SCENARIO  TO  A  FILE 


Selecting  this  option  allows  the  user  to  save  the  scenario  data  into  an  ASCII  file.  There  is 
no  need  to  enter  an  extension  for  the  filename  since  the  extension  ".smd"  is  added  automatically  to 
any  filename  that  you  enter.  Make  sure  that  the  filename  entered  has  fewer  than  eight  characters. 
If  an  extension  is  added  to  the  filename,  that  extension  will  be  dropped  in  favor  of  the  ".smd” 
extension.  The  "insert"  key  can  be  pressed  to  see  a  listing  of  previously  stored  data  sets  if  you  wish 
to  save  your  simulation  data  to  an  existing  file.  In  the  current  version  of  the  Demo,  saving  data  to 
an  existing  file  can  cause  problems  with  the  SYSMOD  Demo  menus.  We  recommend  exiting  from 
SYSMOD  after  saving  a  scenario  and  reentering  the  Demo  to  continue  processing. 

2.7  CONCLUSION 

It  is  important  for  the  user  to  note  that  this  demonstration  software  is  a  first  attempt  to 
illustrate  the  operation  of  SYSMOD  during  Concept  Exploration.  Thus  only  a  few  systems  are 
represented  and  functional  relationships  are  modeled  so  that  changes  in  inputs  produce  changes  in 
outputs  that  are  in  the  appropriate  direction.  As  SYSMOD  is  further  developed,  this  demonstration 
software  can  be  improved  and  expanded  to  include  a  wider  variety  of  trade-off  models  to  assist  the 
analyst  as  well  as  to  elicit  feedback  from  the  Air  Force  user  community. 
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APPENDIX 

SYSMOD  DEMONSTRATION  MODEL  USER’S  MANUAL 
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The  functions  used  in  the  SYSMOD  Demo  are  designed  to  respond  in  the  right  direction  to 
changes  in  inputs.  Because  the  functions  are  simplified  to  yield  results  quickly,  the  user  should  not 
rely  on  the  numerical  results  produced  by  the  functions. 

1.  CONSTRAINED  SORTIE  RATE 

The  constrained  sortie  rate  is  the  total  number  of  sorties  per  day  allowed  by  the  particular 
combination  of  Manpower  Personnel  Training  (MPT)  resources  and  spares.  This  value  is  derived  by 
taking  the  Total  System  Sorties  (TSS)  (defined  below)  and  subtracting  sorties  lost  due  to  one  or  more 
of  the  following  factors;  normal  aircraft  maintenance  downtime,  lack  of  manpower,  or  lack  of  spare 
parts.  Note  that  the  constrained  sortie  rate  can  be  higher  than  the  desired  sortie  rate. 

Finding  the  constrained  sortie  rate  is  an  involved  process.  First,  one  needs  to  find  the  total 
number  of  sorties  that  can  be  flown  under  ideal  conditions,  hereafter  referred  to  as  Total  System 
Sorties.  Ideal  conditions  assume  zero  downtime  for  maintenance  repair,  sufficient  manpower  and 
sufficient  spare  parts.  Therefore 

TSS='¥a 


where  TSS,  Total  System  Sorties,  is  the  wing’s  maximum  possible  sorties  per  day;  T  is  the  maximum 
number  of  sorties  that  can  be  flown  per  day  per  aircraft  given  input  on  the  length  of  the  sorties;  and 
a  is  the  number  of  aircraft  in  the  wing,  assumed  to  be  72  in  the  SYSMOD  Demo.  The  required 
system  sorties  per  day  is  given  by 


a 


(2) 


where  n  is  the  number  of  types  of  missions  flown,  Uj  is  the  number  of  missions  of  type  i  flown  during 
one  day,  and  q|  is  the  number  of  sorties  (aircraft)  required  to  perform  mission  i. 

Finding  the  value  for  T  requires  some  computation  from  the  actual  input  data  received  from 
the  SYSMOD  Demo.  Mission  data  are  entered  into  the  SYSMOD  Demo  using  three  parameters; 
the  number  of  missions  that  are  flown  in  one  day,  the  number  of  aircraft  required  for  that  mission, 
and  the  length  (in  hours)  of  the  sorties  being  flown  on  that  mission.  The  SYSMOD  Demo  allows 
for  up  to  five  mission  types.  Note  that  the  value  of  T  can  have  either  sorties  or  flying  hours  as  its 
unit  of  measurement.  Throuehout  this  appendix,  the  discussion  will  use  the  number  of  sorties  rather 
than  number  of  flying  hours  as  the  unit  of  measurement  for  T.  Using  flying  hours  would  change 
several  formulas  slightly. 
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The  value  of  the  average  length  of  a  sortie  is  given  by 


E  (3) 

r=iii - 

o 

where  T  is  the  average  length  of  the  sorties  in  hours,  n  is  the  number  of  types  of  missions  being 
flown,  Vj  is  the  number  of  missions  of  type  i  flown  during  one  day,  rij  is  the  number  of  sorties 
(aircraft)  required  to  perform  mission  type  i.  A.;  is  the  length  in  hours  of  the  sorties  for  mission  type 
i,  and  o  is  the  required  system  sorties  per  day.  This  formula  is  simply  the  weighted  average  of  the 
mission  lengths  by  the  number  of  sorties  flown  of  that  mission.  The  maximum  possible  number  of 
sorties  per  aircraft  per  day  is 


Sorties  Lost  to  Downtime 

Once  these  parameters  have  been  formulated,  the  total  sortie  loss  due  to  maintenance 
downtime  must  be  calculated.  Calculating  this  downtime  requires  several  steps. 

When  an  aircraft  subsystem  fails,  that  aircraft  is  grounded  and  fixed  before  it  can  fly  again. 
The  time  required  to  perform  the  various  maintenance  tasks  constitutes  lost  sorties  that  the  aircraft 
could  have  flown  had  it  not  been  in  the  shop.  The  expected  value  formula  for  this  downtime  for  any 
given  subsystem  is 

DT^=MTrR.,*iXiMrrR.2)*iY,mTR^)*(l  -X^-Y)MT^R.,*MT^R^  (5) 

where  DTj  is  the  expected  value  of  the  downtime  in  hours  for  subsystem  i,  MTTRjj  is  the  Mean  Time 
To  Repair  in  hours  for  subsystem  i  and  flightline  task  j  (Task  1  is  Troubleshoot,  Task  2  is  Remove 
and  Replace,  Task  3  is  Minor  Repair,  Task  4  is  Cannot  Duplicate,  and  Task  5  is  Verify),  X|  is  the 
probability  Line  Replaceable  Units  (LRUs)  are  removed  and  replaced  after  the  troubleshoot 
operation,  Yj  is  the  probability  LRUs  are  repaired  on  the  flighlline,  and  (l-Xj-Yj)  is  the  probability 
that  no  failure  was  found. 

The  expected  value  of  the  downtime  of  the  weapon  system  can  be  expressed  as  a  function  of 
the  expected  values  of  its  component  subsystems.  This  formula  is 

where  WSDT  is  the  expected  mean  time  to  repair  for  any  given  malfunction  of  the  weapon  system, 
DT;  is  the  expected  value  of  the  downtime  for  subsystem  i,  and  1/MTBFj  is  the  per  sortie  probability 
that  subsystem  i  fails. 
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DT,  \ 


WSDT= 


DT, 


MTBF^  MTBF^  MTBFj 


[MTBFj  MTBF^  MTBF^) 


(6) 


This  formula  may  look  intimidating  but  it  is  actually  only  a  weighted  average  of  probabilities 
and  downtimes.  It  is  logical  that  the  expected  value  of  the  aircraft  downtime  reflects  the  average 
downtimes  of  the  component  subsystems  to  the  degree  that  those  respective  downtimes  occur.  The 
above  formula  weights  the  subsystem  downtime  (DTj)  with  the  probability  that  the  downtime  occurs 
(1/MTBFi). 


Similarly,  the  expected  value  of  the  mean  time  between  failures  (MTBFs)  of  the  weapon 
system  expressed  in  terms  of  its  component  subsystem  MTBFs  is 


SMTBF= - i - 

i- 

MTBF^j^  MTBFj 

where  SMTBF  is  the  expected  value  of  the  MTBF  of  any  component  of  the  weapon  system  and 
MTBF;  is  the  MTBF  of  subsystem  i.  This  formula  is  a  restatement  of  the  law  of  probability  which 
states  that  the  probability  that  the  entire  weapon  system  fails  equals  the  probability  that  any 
subsystem  of  that  weapon  system  fails.  Further,  the  probability  that  any  subsystem  of  the  weapon 
system  fails  is  also  equal  to  one  minus  the  probability  that  all  of  the  subsystems  function  properly. 
Therefore 


n  " 

i=i 


(8) 


where  P(WS'^''"")  is  the  probability  that  the  weapon  system  fails,  P(SSj'“'"”)  is  the  probability  that 
subsystem  i  does  not  fail,  i  denotes  the  subsystem,  and  n  is  the  number  of  subsystems.  Since  there 
are  only  three  representative  subsystems  in  the  Demo,  this  formula  reduces  to  a  much  simpler  one. 
Denoting  P(A)  as  the  probability  that  no  failure  will  occur  (success)  for  subsystem  one  and  P(B)  and 
P(C)  likewise  for  subsystems  2  and  .1,  respectively,  we  have 

P(WS^‘’'’^’^  =  l-P(A)PiB)P{Q 

In  terms  of  MTBFj,  P(A),  P(B)  and  P(C)  can  be  stated  as 
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P(A)=l 


1 

MTBF^ 


P(B)=1 


1 

A/raFj 


(11) 


P(0=i 


1 

MTBF^ 


(12) 


Given  the  probability  of  success  is  one  minus  the  probability  of  failure  and  the  probability  of 
failure  is  the  reciprocal  of  the  MTBF,  we  find  the  formula  given  in  equation  (5). 


Using  the  values  for  the  weapon  system  failure  rate  (equation  5)  and  the  weapon  system 
downtime  (equation  4),  we  can  derive  the  loss  of  sortie  generation  potential  due  to  maintenance 
downtime.  Each  time  an  aircraft  fails,  it  remains  on  the  flightline  for  the  duration  of  the  downtime 
for  that  aircraft.  The  expected  number  of  sorties  that  it  will  miss  is  based  upon  the  expected  length 
of  this  downtime  and  the  expected  length  of  a  sortie.  The  expected  number  of  sorties  lost  for  any 
one  malfunction  is  given  by 

(13) 

r 


where  p  is  the  number  of  sorties  lost  due  to  one  breakdown,  WSDT  is  the  average  downtime  for 
maintenance,  and  F  is  the  average  length  of  a  sortie.  For  every  breakdown  we  can  expect  that  p 
sorties  will  be  lost  and  must  be  subtracted  from  the  sortie  generation  potential.  Now  we  need  to  find 
the  number  of  times  that  this  downtime  occurs.  This  is  simply  a  function  of  the  expected  failure  rate 
of  the  various  components  of  the  weapon  system.  The  formula  for  the  total  number  of  sorties  lost 
due  to  maintenance  downtime  is 


Po 

SMTBF 


(14) 


where  LS^d  sorties  lost  due  to  maintenance  downtime,  p  is  the  number  of  sorties  lost  due  to 
one  breakdown,  o  is  the  required  number  of  system  sorties  (computed  above  from  input  mission 
data),  and  SMTBF  is  the  expected  value  of  the  MTBF  for  the  weapon  system  (computed  above). 
This  is  an  approximation  of  lost  sorties  due  to  maintenance  downtime.  In  reality,  this  relationship 
is  not  strictly  linear  as  it  would  appear  in  equations  13  and  14.  The  more  sorties  lost  due  to  aircraft 
downtime,  the  fewer  sorties  that  can  be  performed.  This  means  that  the  value  of  p  trails  off  at 
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greater  MTBFs  as  downtime  reduces  available  flying  hours  per  day  below  the  number  required  for 
TSS.  We  have  not  illustrated  this  process  here  but  have  modeled  the  phenomenon  in  the  SYSMOD 
Demo  using  a  recursive  procedure. 

Sorties  Lost  to  Manpower  Shortages 

Sections  2  and  3  of  this  Appendix  examine  the  numbers  of  maintainers  that  are  required  for 
each  task  and  Air  Force  Specialty  (APS).  A  shortage  of  flightline  maintainers  would  adversely  affect 
the  sortie  generation  potential.  A  shortage  of  base  level  maintainers  may  also  have  an  effect  on 
sortie  generation  potential.  A  shortage  of  base  level  maintainers  causes  an  increase  in  the  number 
of  spare  LRUs  required.  If  this  requirement  for  spares  is  not  met,  then  sortie  generation  potential 
suffers.  Thus,  a  shortage  of  base  level  maintainers  causes  a  shortage  of  spares  that  causes  a  decrease 
in  sortie  generation.  The  effects  of  spare  deficiencies  on  sortie  generation  potential  is  discussed  later 
in  this  section.  Hereafter  in  this  discussion  of  the  effects  of  manpower  shortages  on  the  sortie 
generation  rate,  references  to  AFSs  will  mean  flightline  AFSs  only. 


The  effects  on  the  sortie  rate  of  a  shortage  of  people  in  an  AFS  are  not  easily  derived  since 
one  AFS  can  work  on  several  tasks  from  .several  subsystems.  What  must  be  done  first  is  to  determine 
which  AFSs  have  shortages  and  where  tho.se  shortages  limit  the  rate  at  which  an  aircraft  in  need  of 
repair  moves  through  the  repair  system.  Calculating  the  effect  on  sortie  rate  is  then  a  matter  of 
identifying  the  task  probability  and  repair  lime  combination  that  limits  the  number  of  repairs  the 
most.  The  formula  for  calculating  sorties  lost  due  to  manpower  shortages  is 


a  , 


b.j,SHRT,,P,Bi\-d) 


ij*-  V 


MTTR.. 


(15) 


where  a/a  is  the  wing’s  required  sorties  per  day;  6jj^  is  one  when  task  j  on  subsystem  i  is  assigned  to 
AFS  k  and  zero,  otherwise;  SHRT  is  the  number  of  crews  AFS  k  is  short  per  day  for  task  j  on 
subsystem  i;  Pjj  is  the  probability  that  task  j  is  needed  when  subsystem  i  fails  (See  Figure  A-1.); 
8(1 -0|.)  is  the  hours  of  an  eight  hour  shift  that  a  crew  from  AFS  k  is  available  to  perform 
maintenance;  MTTRjj  is  the  mean  time  to  accomplish  task  j  on  subsystem  i. 


The  total  number  of  sorties  lost  per  day  due  to  manpower  shortages  is  given  by  the  sum  of 
the  losses  due  to  each  subsystem. 


(16) 
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It  is  reasonable  to  conclude  that  the  effect  of  manpower  shortages  on  sortie  generation 
potential  decreases  as  the  manpower  shortages  increase.  That  is,  the  14th  missing  maintainer  does 
not  contribute  as  much  to  the  lost  of  sortie  generation  potential  as  the  first  missing  maintainer  does. 
This  is  because  the  effect  of  that  maintainer  on  the  loss  of  sortie  generation  potential  is  proportional 
to  the  sortie  rate  that  can  be  achieved.  As  we  lose  maintainers,  the  sortie  rate  decreases.  The  sorties 
lost  due  to  manpower  shortages,  LS^s-  are  modeled  in  SYSMOD  using  a  recursive  procedure  that 
tracks  this  marginal  effect  for  all  of  the  mission  AFSs. 

Sorties  Lost  to  Spares  Shortages 

Subsystem  failures  generate  a  requirement  for  spare  LRUs.  Should  this  spares  requirement 
not  be  met,  a  loss  in  sortie  generation  potential  results.  This  is  the  third  factor  that  can  decrease  the 
constrained  sortie  rate  and  hence  the  performance  of  the  system  as  a  whole.  If  there  is  a  shortage 
in  spares  of  any  subsystem,  this  causes  the  aircraft  to  be  down.  The  formula  quantifying  lost  sorties 
due  to  spares  shortages  is 

LS;^,=-MAX(RS^-S^,RS2-S^JiS^-SyO)  (*7) 

CL 

where  LSjd  is  the  lost  sorties  due  to  spares  deficiencies,  o/a  is  the  required  sorties  per  aircraft  per 
day,  Sj  is  the  number  of  spares  available  for  subsystem  i,  and  RSj  is  the  number  of  spares  required 
for  subsystem  i  (defined  in  Section  8). 

Thus  the  constrained  sortie  rate  can  be  stated  as 

CS=TSS-LS^^-LS,,,-LS,^  (18) 

where  CS  is  the  constrained  sortie  rate,  TSS  is  the  total  system  sorties,  LS^jp  is  the  sorties  lost  due 
to  maintenance  downtime,  LS^s  is  the  sorties  lost  due  to  manpower  shortages,  and  LSs^  is  the  sorties 
lost  due  to  spare  deficiencies. 

2.  WORKLOAD  PER  TASK 

This  term  refers  to  the  number  of  maintainers  that  are  required  to  perform  any  particular 
task.  Flightline  tasks  are  Troubleshoot,  Remove  and  Replace,  Cannot  Duplicate,  Minor  Repair  and 
Verify.  Base  level  tasks  consist  of  Troubleshoot  and  Major  Repair.  The  manning  required  to 
perform  a  particular  task  is  defined  by 

TM  -  (19) 

v  S{l-e^)MTBF. 
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where  TMij  is  the  Total  Manning  for  task  j  on  subsystem  i;  Njj  is  the  number  of  maintainers  for 
subsystem  i  and  task  j;  MTTRjj  is  the  expected  time  to  complete  task  j  on  subsystem  i,  Pjj  is  the 
probability  that  task  j  will  be  required  for  a  failed  subsystem  i,  a  is  the  wing’s  required  sorties  per  day; 
8(1-0|()  is  the  number  of  hours  each  day  that  members  of  AFS  k  are  available  to  perform 
maintenance;  and  MTBFj  is  the  mean  number  of  sorties  between  failures  for  subsystem  i. 

To  define  the  values  of  Pjj,  please  refer  to  Figures  A-1  and  A-2  in  Section  8  of  this  Appendix. 
These  figures  show  the  maintenance  network  for  both  the  flightline  level  and  the  base  level.  Let’s 
first  look  at  the  flightline  level  and  define  Pjj  for  each  task. 

Troubleshoot  (Task  1):  The  value  of  Pj,  equals  1  since  all  tasks  must  go  through  the 
troubleshoot  operation  to  determine  the  cause  of  malfunction.  Remove/Replace  (Task  2):  The  value 
of  Pj2  equals  the  value  assigned  to  Xj.  Minor  Repair  (Task  ?>)'.  The  value  of  Pjj  equals  the  value 
assigned  to  Yj.  Cannot  Duplicate  (Task  4);  The  value  of  Pi4  equals  (1-Xj-Yj).  Verify  (Task  5):  The 
value  of  P|5  equals  1  since  every  aircraft  must  go  through  the  Verify  procedure  in  order  to  be  released 
to  fly  sorties. 

For  base  level  repair  refer  to  Figure  A-2  but  remember  that  in  order  for  a  defective  LRU  to 
get  to  the  base  level,  it  first  must  go  through  the  Remove/Replace  operation  on  the  flightline.  That 
means  that  any  probabilities  on  the  base  level  must  be  multiplied  by  Xj,  the  probability  of  an  LRU 
being  removed  and  replaced  on  the  flightline.  The  values  for  Pjj  for  base  level  maintenance  follow: 
Troubleshoot  (Task  1):  Pj,  =  Xj;  Major  Repair  (Task  2):  Pj2  =  XjZj. 

3.  MANNING  FOR  AFS 

The  total  manning  for  each  AFS  is  computed  by  a  simple  expected  value  formula.  In  the 
SYSMOD  Demo,  each  of  the  three  subsystems  has  five  flightline  and  two  base  level  tasks.  Each  of 
these  tasks  requires  a  workcrew  of  one  to  three  maintainers.  Each  task  has  an  assigned  AFS;  the  first 
three  AFSs  are  restricted  to  flightline  work,  while  the  final  three  AFSs  are  restricted  to  base  level 
work.  Maintainers  are  divided  within  their  AFSs  into  skill  levels  or  grades;  however,  for  the 
discussion  in  this  manual,  skill  levels  are  used. 

The  total  manning  for  an  AFS  depends  upon  how  many  tasks  are  assigned  to  that  AFS.  Since 
an  AFS  can  be  assigned  to  any  number  of  tasks,  the  total  manning  for  any  given  AFS  is 
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(20) 


(-1  y-1 

where  AFSM^  is  the  manning  for  APS  k;  Sjjk  is  1  if  task  j  for  subsystem  i  is  assigned  to  APS  k  and 
0  otherwise;  and  TMjj  is  defined  in  Equation  17. 

Simply  stated,  the  total  manning  for  any  APS  k  is  the  sum  of  the  manning  for  all  of  the  tasks 
(explained  in  Section  2  of  the  Appendix)  assigned  to  that  APS. 

4.  BASE  OPERATING  SUPPORT  NUNNING 

This  term  refers  to  the  total  manpower  that  is  required  for  Base  Operating  Support  (BOS). 
This  value  is  set  at  14%  of  the  total  manpower  requirements  for  all  maintenance  related  APSs.  This 
14%  factor  is  an  average  factor  used  by  the  Air  Force  Management  Engineering  Agency  (APMEA). 

5.  TRAINING  LENGTH 

The  SYSMOD  Demo  simplifies  the  training  process  for  aircraft  maintainers  by  dividing 
training  into  two  categories;  classroom  (technical  school)  and  Field  Training  Detachment  (FTD). 
A  maintainer  assigned  to  each  task  for  each  subsystem  requires  certain  amounts  of  training  in  these 
two  settings  to  adequately  perform  that  task.  Each  subsystem  task  for  both  flightline  and  base  level 
has  four  different  sets  of  training  times,  one  for  each  skill  level  (.^,  5,  7,  and  9).  When  an  APS  is 
assigned  to  two  or  more  tasks,  the  APS  requires  training  in  all  of  these  tasks.  The  SYSMOD  Demo 
assumes  that  some  of  the  training  for  different  tasks  will  be  repetitive  and  thus  the  total  training  time 
will  be  less  than  the  sum  of  the  training  times  for  each  task  assigned  to  the  APS.  The  formula  that 
the  SYSMOD  Demo  uses  to  estimate  the  amount  of  training  time  required  for  an  APS  is 

.<FSrr...8,r*2EE^.<, 

i-i  y-i 

where  APSTr^  is  the  amount  of  training  required  for  AFS  k;  Cjj,.  is  one  if  task  j  on  subsystem  i  is 
assigned  to  APS  k,  and  zero  otherwise;  t  jj  is  the  training  time  required  for  task  j  on  subsystem  i;  and 
is  the  training  time  that  is  the  longest  of  all  of  the  tasks  allocated  to  APS  k. 

The  above  formula  is  applied  to  both  classroom  and  FTD  training.  Essentially,  this  formula 
says  that  in  order  to  adequately  train  an  AFS  for  multiple  tasks,  the  total  training  time  will  equal  the 
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longest  training  time  of  those  tasks  plus  20  percent  of  the  remaining  training  times.  Reminder:  This 
formula  is  an  approximation  for  purposes  of  the  Demo. 

6.  COST  OF  SPARES  AS  A  FUNCTION  OF  MEAN  TIME  BETWEEN  FAILURES 

For  each  subsystem  there  is  an  associated  MTBF.  Improving  the  MTBF  of  a  subsystem 
requires  additional  resources  for  the  research,  development,  and  production  efforts  that  go  into 
making  any  product  more  reliable.  These  additional  resources  increase  the  cost  of  the  spare  LRUs. 

In  the  SYSMOD  Demo,  the  relationship  between  increased  reliability  (greater  MTBF)  and 
cost  of  spares  is  assumed  to  be  proportional.  In  other  words,  an  increase  in  MTBF  of  Y  percent 
increases  the  cost  of  any  spare  LRUs  purchased  by  X  percent. 

For  example,  assume  a  propulsion  system  has  a  MTBF  of  120  sorties  and  the  cost  of  an  LRU 
is  $240,000.  If  the  user  requests  that  the  MTBF  be  increased  to  150  sorties,  the  model  changes  the 
price  of  one  spare  for  this  propulsion  system  to  S.mOOO  (i.e.  a  25%  increase  in  both  MTBF  and  the 
price).  Note:  These  automatic  changes  only  occur  in  the  trade-off  section  of  the  model.  During 
initial  parameter  input,  the  MTBF  and  the  cost  of  spares  can  be  set  without  regard  to  this 
proportional  relationship.  Also,  if  during  a  trade-off  the  user  feels  that  the  relationship  does  not 
hold,  there  is  an  override  key  that  can  be  used  to  set  the  MTBF  and  the  cost  of  spares  independently. 
The  instructions  for  this  are  detailed  in  Section  2.5.1  of  the  user  manual. 

7,  FLIGIITLINE  WORKLOAD  AS  A  FUNCTION  OF  MEAN  1 IME  BEIWEEN  FAILURES 

Changing  the  MTBF  of  any  subsystem  will  affect  the  workload  of  flightline  maintamers  who 
repair  that  subsystem.  Sometimes,  different  AFSs  work  on  the  same  subsystem,  so  that  a  change  m 
the  MTBF  of  one  subsystem  causes  changes  in  the  manpower  requirements  in  more  than  one  AFS. 

To  examine  the  effect  that  MTBF  has  on  Hightline  workload,  we  must  look  at  the  relationship 
between  the  two  variables.  In  this  case,  flightline  workload  is  a  function  of  the  MTBF  of  the 
subsystem.  The  expected  value  formula  relating  these  two  variables,  as  used  in  the  SYSMOD  Demo 

software,  is 


i-i  i-i 


(22) 


where  W,  is  the  flightline  workload  for  AFS  k  (measured  in  hours  of  maintenance);  is  one  if  task 
j  of  subsystem  i  is  assigned  to  AFS  k,  and  zero  otherwise;  o  is  the  number  of  sorties  flown  by  the  wing 
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per  day;  Njj  is  the  number  of  maintainers  in  a  workcrew  for  subsystem  i  and  task  j;  MTTRjj  is  the 
MTTR  for  task  j  on  subsystem  i  (measured  in  hours);  and  MTBFj  is  the  MTBF  for  subsystem  i 
(measured  in  sorties'). 

From  this  formula  we  can  see  that  as  the  MTBF  of  a  subsystem  increases,  the  number  of 
maintainers  required  for  this  subsystem  decreases.  In  order  to  better  show  how  this  relationship 
works,  a  notional  example  is  provided; 


Consider  the  case  of  determining  the  flightline  level  workload  for  AFS  1.  AFS  1  is 
assigned  to  work  on  Subsystem  1,  Task  1  (Airframe,  Troubleshoot)  and  Subsystem  2, 
Task  1  (Propulsion,  Troubleshoot).  Tlie  parameters  are  defined  as  follows: 


W, 

8,1. 

8211 

o 

Nn 

N2, 

MTTR,, 

MTTR2, 

MTBF, 

MTBF, 


=  Flightline  workload  for  AFS  1  (maintainer-hours/day) 
=  1 
=  1 

=  360  sorties/day 
=  3  maintainers 
=  2  maintainers 
=  1.5  hours/failure 
=  2.5  hours/failure 
=  50  sorties/failure 
=  30  sorties/failure 


The  flightline  workload  for  this  case  is: 

2  1 

W^=Y,Y,\O(>0*N^*MTTR.p|MTBF^ 


(23) 


which  is: 

IF,=(360*3*1.5)/50+(360+2*2.5)/30=32.4460  (24) 


=  92.4  maintainer-hours/day 


'  This  formula  applies  when  sortie  rate  is  used  as  the  flight  frequency  parameter.  The  formula 
differs  slightly  when  flying  hours  are  used. 
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Using  an  overhead  fraction  of  .22  and  the  eight  hour  workday  assumed  in  the  Demo, 
92.4/(8(l-.22))  =  14.8  or  15  maintainers  are  required  to  handle  the  workload  for 

AFS  1. 

The  relationship  between  flightline  workload  and  MTBF  is  not  strictly  linear  when  considered 
in  the  broader  sense.  In  other  words,  since  different  AFSs  work  on  different  tasks  for  any  given 
subsystem,  the  relationship  is  difficult  to  approximate.  The  model  re-calculates  the  flightline 
workloads  given  the  new  MTBF(s)  in  the  trade-off  screen. 

8.  MINIMUM  NUMBER  OF  SPARES  REQUIRED 

The  SYSMOD  Demo  allows  for  two  levels  of  maintenance:  the  flightline  and  the  base  level. 
For  each  of  these  levels  of  maintenance,  there  is  a  maintenance  network  that  defines  the  path  that 
a  particular  LRU  takes  after  it  has  failed.  The  flightline  subsystem  looks  like  the  graph  depicted  in 
Figure  A-1. 


Figure  A-1.  Flightline  Level  Maintenance  Network 


Following  a  failed  LRU  though  the  network,  we  find  that  the  LRU  goes  immediately  to 
Troubleshoot.  Once  this  task  is  completed,  the  LRU  goes  to  one  of  three  options  with  a  given 
probability.  With  probability  X,  the  LRU  is  Removed  and  Replaced  with  a  spare  LRU,  and  the 
defective  LRU  is  sent  to  the  base  level  for  further  diagnosis  and  repair.  With  probability  (1-X-Y), 
the  tests  show  nothing  wrong  with  the  LRU.  With  probability  Y,  the  LRU  requires  a  Minor  Repair 
which  is  done  right  on  the  flightline.  From  all  three  branches,  the  next  step  is  to  Verify  the 
performance  of  the  LRU  on  the  aircraft  before  the  aircraft  is  released  from  maintenance.  The 
branch  that  we  are  most  interested  in  at  this  point  is  the  branch  that  sends  the  defective  LRU  to  the 
Base  Level  for  further  action.  Once  the  LRU  is  sent  to  this  branch,  it  continues  through  the  network 
shown  in  Figure  A-2. 
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Figure  A-2.  Base  Level  Maintenance  Network 

Once  at  the  base  level,  the  LRU  goes  immediately  to  the  base  level  Troubleshoot  operation. 
Upon  completion  of  this  step,  the  LRU  goes  to  one  of  two  options.  With  probability  Z,  the  LRU 
undergoes  a  Major  Repair  and  then  is  returned  to  stock.  With  probability  (1-Z),  the  LRU  is 
irreparable  and  is  sent  to  salvage.  This  final  branch  is  what  we  are  most  interested  in  to  explain  the 
concept  of  minimum  number  of  spares  required. 

With  a  non-zero  probability  of  LRUs  being  lost  to  salvage,  we  have  introduced  a  sink  for 
spares  for  every  subsystem.  We  must  introduce  a  corresponding  source  to  refresh  the  supply  of 
spares  lest  that  supply  dwindle  to  zero  and  cause  a  loss  of  sortie  generation  potential.  In  other  words, 
one  must  purchase  additional  LRUs  on  a  daily  basis  to  replenish  the  loss  to  the  inventory  of  spare 
LRUs  caused  when  LRU’s  are  salvaged,  not  repaired.  Note  that  this  assumes  steady  state  equilibrium 
with  respect  to  spares. 

The  minimum  number  of  spares  to  be  purchased  is  governed  by  the  relationship  between 
several  parameters.  The  value  of  the  minimum  expected  spare  purchase  per  day  can  be  found  using 


RSi= 


(X,(l-Z.)o) 

MTBFi 


(25) 


where  RSj  is  the  number  of  spares  required  per  day  for  subsystem  i,  Xj  is  the  probability  that  the 
LRU  is  removed  and  replaced  after  the  flightline  troubleshoot  (as  illustrated  in  Figure  A-1),  (1-Z.j) 
is  the  probability  that  the  LRU  is  sent  to  salvage  after  the  base  level  troubleshoot  (as  illustrated  in 
Figure  A-2),  o  is  the  wing’s  required  sorties  per  day,  and  MTBFj  is  the  MTBF  for  subsystem  i 
(measured  in  sorties). 
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This  formula  can  be  derived  by  taking  the  total  number  of  subsystem  failures  (o/MTBFj)  and 
following  those  LRUs  though  the  two  maintenance  networks  to  get  the  number  of  failed  LRUs  that 
eventually  find  their  way  to  salvage. 

The  minimum  monthly  spares  purchase  is  zero  only  in  certain  circumstances:  1)  there  are  no 
sorties  being  flown,  2)  parts  are  always  repaired  on  the  flightline  (i.e.  X  equals  zero),  or  3)  no  LRUs 
are  sent  to  salvage  (i.e.  Z  equals  one). 

9.  NUMBER  OF  SPARES  AS  A  FUNCTION  OF  NUMBER  OF  BASE  LEVEL  MAINTAINERS 


Base  level  maintainers  perform  troubleshooting  and  major  repairs  on  LRUs  that  cannot  be 
fixed  on  the  flightline.  Essentially,  base  level  maintainers  take  LRUs  that  would  otherwise  be 
unusable  and  make  them  usable  again.  Thus  the  effect  of  a  shortage  of  base  level  maintainers  is  a 
loss  of  spares  that  come  back  into  the  system.  In  order  to  make  up  this  deficiency,  additional  spares 
must  be  purchased. 

As  discussed  in  the  previous  section,  there  is  a  minimum  level  of  spares  that  must  be 
purchased  in  order  to  maintain  equilibrium  for  sortie  generation  potential.  The  lower  bound  occurs 
when  there  are  no  shortages  of  base  level  maintainers  to  repair  LRUs  and  return  them  to  stock. 
There  is  also  an  upper  bound  over  which  additional  spares  do  not  contribute  to  a  greater  number  of 
sorties;  they  are  wasted.  This  level  of  spares  occurs  when  the  number  of  base  level  maintainers  drops 
to  zero  (or  when  the  option  for  base  level  maintenance  is  not  selected  in  the  SYSMOD  input 
screens). 

Similarly,  there  is  an  effective  range  for  base  level  maintainers.  The  lower  bound  is  simply 
zero.  The  upper  bound  represents  the  number  of  maintainers  required  to  meet  demand  and  keep 
the  monthly  spares  purchase  to  its  lower  bound.  The  initial  numbers  on  the  Man-Machine  trade-off 
screen  show  the  numbers  of  base  level  maintainers  at  their  upper  bounds  and  the  numbers  of  spares 
at  their  lower  bounds. 

The  relationship  between  base  level  maintainers  and  the  number  of  spares  required  can  be 
derived  from  an  equation  relating  the  rate  at  which  LRUs  fail  and  the  rate  at  which  new  or  repaired 
LRUs  are  sent  to  the  flightline  for  use.  For  steady  state  equilibrium,  the  number  of  spares  sent  to 
the  base  due  to  malfunction  must  equal  the  number  the  spares  sent  to  the  flightline  via  either  repair 
from  base  level  maintenance  or  from  additional  spares  purchases.  Therefore,  to  maintain  steady  state 
equilibrium 
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(26) 


where  Si(t)  is  the  flow  of  new  or  repaire'd  spare  LRUs  for  subsystem  i  to  the  flightline  over  time  t 
and  Lj(t)  is  the  flow  of  failed  LRUs  for  subsystem  i  to  base  level  repair.  We  can  formulate  equations 
for  each  of  the  variables  Li(t)  and  Si(t).  For  a  time  period  of  one  day  the  expected  number  of  units 
of  subsystem  i  sent  to  base  level  for  repair,  Lj,  is  given  by 


'  MTBF, 


(27) 


where  X;  is  the  probability  a  failure  is  due  to  a  malfunctioning  LRU  that  must  be  sent  to  base  level 
for  repair,  o  is  wing’s  required  sorties  per  day,  and  MTBFj  is  the  Mean  Time  (sorties)  Between 
Failures  for  subsystem  i. 


The  number  of  LRUs  generated  during  a  day  is  a  combination  of  those  purchased  and  those 
repaired  by  base  level  maintainers 


(28) 


where  the  second  subscript  on  S;  indicates  units  purchased  (p)  or  repaired  (r).  To  repair  an  LRU 
both  the  troubleshoot  and  the  major  repair  tasks  must  be  accomplished.  Let  us  look  at  the  capacity 
of  base  level  maintainers  for  conducting  the  troubleshoot  task  (task  1,  j  =  l): 


AFS^  8(1 -0^) 


c,,=- 

"  MTTR,, 


(29) 


and  for  conducting  the  major  repair  task  (task  2,  j=2): 

AFS.  8(1-0.) 
^  ^ 
“  A/rn?„ 


(30) 


where  the  second  subscript  on  C  indicates  the  task,  represents  the  total  number  of  workcrews 

from  AFS  k  that  are  assigned  to  task  j  on  subsystem  i  over  the  day,  8(1 -0i.)  is  the  number  of  hours 
each  crew  of  AFS  k  is  available  for  performing  maintenance  each  day,  and  MTTRjj  is  the  expected 
time  to  accomplish  task  j  on  subsystem  i. 

The  number  of  failed  units  of  subsystem  i  that  can  be  processed  by  the  AFS  responsible  for 
troubleshooting  is: 
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(31) 


which  is  simply  the  minimum  of  the  units,  that  need  troubleshooting  and  the  capacity  of  maintainers 
to  provide  troubleshooting. 


The  number  of  units  of  subsystem  i  that  can  be  processed  by  the  AFS  responsible  for  major 


repairs  is; 


(32) 


which  is  the  minimum  of  the  units  that  reach  the  major  repair  task  (see  Figure  A-2)  and  the  capacity 
of  maintainers  to  conducting  major  repairs.  But  this  is  the  number  of  units  of  subsystem  i  repaired 
each  day: 


Thus  the  number  of  spares  for  sub.system  i  that  must  be  purchased  each  day  to  prevent  a 
shortage  of  spares  over  the  long  run  is  given  by 


10.  TASK  TIME  AS  A  FUNCTION  OF  EXPERIENCE 

Each  particular  task  is  handled  by  a  workcrew.  Tlie  SYSMOD  Demo  allows  workcrew  sizes 
to  vary  from  one  to  three  maintainers.  Each  maintainer  can  have  a  different  experience  level,  defined 
here  as  a  skill  level  of  3,  5,  7,  or  9  (or  grade  level  4,  5,  6,  or  7).  It  is  reasonable  to  assume  that  a 
maintainer  with  more  training  and  experience  can  perform  the  same  task  faster  than  one  who  has  less 
training  and  experience.  The  Man-Man  Trade-offs  allow  for  changing  experience  level  (and  hence 
salary)  for  faster  or  slower  task  times.  This  section  will  explain  the  methodology  behind  the 
quantification  of  this  relationship. 

In  the  input  screens  of  the  SYSMOD  Demo,  the  user  enters  several  parameters,  among  them 
the  skill  levels  (or  grades)  of  the  members  of  all  of  the  workcrews.  The  experience  level  -  task  time 
trade-off  screen  allows  the  user  to  change  the  skill  levels  (grades)  of  the  flightline  or  base  level 
workcrews  to  see  how  these  changes  affect:  a)  the  performance  time  for  that  task  b)  the  overall 
performance  of  the  system  and  c)  the  wage  costs  of  the  maintainers.  When  the  user  replaces  an 
airman  of  low  skill  level  with  one  of  higher  skill  level,  the  task  time  for  that  particular  task  goes  down 
and  vice  versa.  The  SYSMOD  Demo  gives  greater  weight  to  experience  changes  in  flightline  and 
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base  level  troubleshoot  tasks.  It  is  reasoned  that  experience  plays  a  greater  role  in  troubleshooting 
than  in  other  more  straightforward  tasks.  The  effect  of  changing  the  experience  level  of  one 
maintainer  in  a  troubleshooting  workcrew  is: 

SL 

Afmjr=[(— ^-l)/«..+  l]M7TR,;“  (35) 

"  Sir 


The  effect  of  experience  changes  on  other  tasks  is  simply  watered  down  according  to 

SL. 

A/7T;?,P’=t(— ^  -1)/(2q  .p  +  (36) 

where  SV"*  is  the  new  skill  level  for  AFS  k,  84“'''  is  the  old  skill  level  for  AFS  k,  and  is  the  size 
of  the  workcrew  for  subsystem  i  and  task  j. 

The  difference  between  the.se  two  formulas  is  that  in  non-troubleshooting  tasks,  the 
percentage  multiplier  has  been  cut  in  half  (i.e.  what  would  be  a  10%  increase  in  task  time  for 
troubleshoot,  a  multiplier  of  1.10,  would  be  a  5%  increase  in  a  non-troubleshooting  task,  a  multiplier 
of  1.05). 


11.  GLOSSARY 


TSS 

T 

a 

a 

n 

’ll 

r 

DTj 

MTTRjj 

Yi 

MTBFi 


Total  System  Sorties  by  all  wing  aircraft  (sorties/day)(theoretical  maximum) 
Maximum  number  of  sorties  per  day  by  a  single  aircraft  (sorties/day/aircraft) 
Number  of  aircraft  in  the  wing  (72  in  SYSMOD)  (aircraft) 

Required  system  sorties  (sortie.s/day) 

Number  of  types  of  missions  flown 

Number  of  missions  of  type  i  per  day  (Missions/day) 

Number  of  aircraft  required  to  perform  mission  type  i.  (Sorties/mission) 

Average  sortie  length  (hours/sortie) 

Length  of  sortie  for  mission  number  i  (hours/sortie) 

Expected  value  of  downtime  for  subsystem  i  (hours/failure) 

Mean  Time  To  Repair  subsystem  i,  task  j  (hours/failure) 

Probability  that  subsystem  i  LRUs  are  removed  and  replaced  after  the  troubleshoot 
operation 

Probability  that  subsystem  i  LRUs  are  repaired  on  the  flightline 
Mean  Time  Between  Failures  (sorties/failure) 
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t 

! 


1/MTBFj 

WSDT 

SMTBF 


P 

LSmd 

LSms 

(lA) 


®ijk 

SHRTijk 

Pii 

L^sd 

S, 


RSi 

cs 

TMij 

Nii 

AFSMk 

AFSTri 


-max 
^  k 

Wk 

Xi 

(1-zo 

Si(t) 

Li(t) 

S4""' 

SLi"'*' 


Probability  that  subsystem  i  fails 

Expected  mean  time  to  repair  for  the  weapon  system  (hours/failure) 

Expected  value  of  the  MTBF  for  the  weapon  system  (sorties/failure) 

Sorties  lost  due  to  one  breakdown  (sorties/failure) 

Sorties  lost  due  to  maintenance  downtime  (Sorties/day) 

Sorties  lost  due  to  manpower  shortage  (Sorties/day) 

Fraction  of  time  that  a  crew  is  available  to  perform  maintenance 
1  if  condition  is  met,  and  zero  otherwise 

Number  of  crews  APS  k  is  short  for  task  j  on  subsystem  i  (Crews) 

Probability  that  task  j  must  be  performed  when  subsystem  i  fails 
Sorties  lost  due  to  spares  shortage  (Sorties/day) 

Number  of  spares  available  for  subsystem  i  through  purchase  or  repair  (Spares) 
Number  of  spares  required  for  subsystem  i  (Spares) 

Constrained  sortie  rate  (Sorties/day) 

Total  manning  for  task  j  on  subsystem  i  (Maintainers) 

Number  of  maintainers  in  a  workcrew  for  subsystem  i  and  task  j  (Maintainers) 
Manning  for  AFS  k  (Maintainers) 

Training  required  for  AFS  k  (Weeks) 

Training  time  required  for  task  j  on  subsystem  i  (Weeks) 

Training  time  that  is  the  longest  of  all  of  the  tasks  allocated  to  AFS  k.(Weeks) 
Flightline  workload  for  AFS  k  (maintainer-hours/day) 

Probability  that  the  LRU  is  removed  and  replaced  after  the  flightline  troubleshoot. 
Probability  that  the  LRU  is  sent  to  salvage  after  the  base  level  troubleshoot. 

Flow  of  new  or  repaired  spare  LRUs  for  subsystem  i  to  the  flightline  over  time  t. 
Eow  of  failed  LRUs  for  subsystem  i  to  base  level  repair. 

New  skill  level  for  AFS  k. 

Old  skill  level  for  AFS  k. 

Size  of  the  workcrew  for  subsystem  i  and  task  j.  (Maintainers) 

Spares  purchased  for  subsystem  i.  (Spares/day) 

Spares  generated  through  repair  for  subsystem  i.  (Spares/day) 

Workcrews  per  day  assigned  to  task  j,  subsystem  i  from  AFS  k.  (crews/day) 
Capacity  of  base  level  maintainers  to  perform  task  j  on  subsystem  i.  (Repairs/day) 
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